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NESTED RELATIONAL DATA MODEL 

nOP-\TaGHT NOTICE 
A portion of the disclosure of this patent document contains material that 
is subject to copyright protection. The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent disclosure as it appears in 
the Patent and Trademark Office patent file or records, but otherwise reserves aU 
copyright rights whatsoever. 

FTKm OF THE TWRNTION 
The present invention relates to inforaiation management in general and 
more particularly to methods for using Nested Relational Data Models (NKDMs) to 
manage infomiation. 

B ACKGRQLTND OF THE TWK>JnON 
Information is commonly managed in units of documents. For example, 
sales, distribution and manufacturimg information might be contained within documents 
such as sales invoices or orders. Increasingly, documents pass between parties in 
electronic fomi. in a process generally referred to as EDI (Electronic Data Interchange). 
In electronic fomi, the documents are not limited to the text and images shown on the 
printed page, but can include formatting and "metadata" (data about the data). One 
example of a format for an electronic document that contains metadata is the Extended 
Markup Language (XML). 

Several products on the market aUow mapping of XML documents to SQL 
tables or vice versa and several products on the market aUow mapping of EDI documents 
to relational tables or vice versa, but these products typically require procedural 
specifications of how to perform the conversion, such as programming code. Traditional 
Relational Database Management Systems (RDMS's) such as described by Date or 
Ullman or implemented by Oracle, IBM, Microsoft and others as well as distributed 
databases as described in Ceri or U.S. Patent Nos. 5,884,3 10 and 5,596,744, implement 
declarative transformations of relational data. 

A class of systems called intelligent gateways (such as Sybase's 
OmniServer system) allow declarative mles to be transparently appHed to heterogeneous 
relational databases. Another class of systems called Replication Servers (such as 
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described iyUS. Patent No. 5.737,601 ortaptemented as Sybase's R=pM» Server, 
Oracle's RepUcation server, or the lite)ca.pmvidehomogeneom or hetemgeneousd^ 

replication. 

Additional dass of systems called lie BTL (ExIraotioD, liMfcrnBSon. 
Loading) systems such as Microsoft DTS, InfoiroaticaPoweMart and D2K Tapestry 
provide eKtraction. malformation and loading of heterogeneous databetweenrotatroual 
database systems. Some offbese products support converting hierarchical files n>toa 

relational fbrmby--ilat.em»g--«- hierarchical ffl=s.maldngmultiplepasse=te^^^ 
hierarchical file ar>d, at each pass, pulling out difierent parts of the hierarchy. 

Yet another class of systems that address mapping of relational data to . 
programming object, as ..amplified by U.S.Pat^Nos. 6.175.837. 6,163,781. 
6 134 559 5907 846. 5.S73.093. 5,832.498. orproducts6omP=rsistence.BeaaBi 
otters', ms'class of tools maps persistenfly s.pr«l relatioaal data to an object^rtented 
memory representation as wdl as mapping the data fiom an obj ect-oriented memory 
represemafion to a set of persistent relational tables. 

Another class ofprior art exists that provides object-oriented acc«s to 

non-relational databases, as described inU.S.Paten.Nos. 5.799.313.5,778379, and 
5 542 07S This class of systems addresses die mwmg of data fiomhrerarchrcal 
dltablses such as IMS, object oriented d^ases and reladonal databases to an 
) object-oiientedprogramming objector database. 

Considerable research has been dene on Nested RelationalDataModels as 

described in_. "Lecmre Notes in Con-puter Science Volume 595: M. Levene - The 
Nested Universal Belation Database Modd"=nd__,"LectareNo,es in Con.pu.er 

science Volume 361: S. Abiteboul et al. -Nested Relations andComple. Objec^ m 
5 Databases". That research focused mainly on defining flxe data model and spectflo 

Operations on it v «*v,«- <5^f. for 

It U known to graphically map disparate schemas to each other. See, 
exarnple,U.S.PatentNos.5,850,631 and5.806,066.Itisalsol^ownto^^ 
.etweendi^-erentstnactures. See for example, U.S. Patent Nos. 5,627,972 and 5,119,465. 

CTTK/TM ARY OF rPTF mVHNTION 
m one embodiment of data processing system according to 1iie present 
invention, hierarchical documents or hierarchical messages axe mapped to aNested 
Relational DataModel to allow for transformation and mamp^^ationusmgdecl^^^^^^ 
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Statements. The resultmg nested data can be converted to a relational format and mapped 
to multiple relational tables, and/or converted from a nested relational format to an 
external hierarchical format, such as XML. 

The system can specify and execute declarative rules to extract, transform, 
integrate, load and update hierarchical and relational data. The system can also be used 
for extending documents- with relational and non-relational data and applying updates 
based on these documents to relational database targets. The system can also be used for 
mapping Nested Relational Data to function calls that accept tables as parameters and 
return multiple scalar and table parameters as output 

T^T^TRF nHSnRIPTIQN nv TBTP. DRAWINGS 
Fig! 1 shows a table that is related to a single row of another table. 
' Fig. 2 shows the data of Fig. 1, organized as multiple rows in a single 



Fig. 3 shows the data of Fig. 1, organized as multiple tables related by a 



15 join. 



Fig. 4 illxistrates multiple levels of nested tables contained in one column. 
Fig. 5 illustrates a more general example of multiple levels of nested tables 
contained in more than one column. 

Fig. 6 is a block diagram of a database system according to one 
embodiment of the present invention. 

Fig. 7 illustrates schema relating to nested tables; Fig. 7 A shows mput 
tables and Fig. 7B shows an output schema 

Fig. 8 illustrates a process of grouping values across nested tables. 
Fig. 9 illustrates a process of unnesting data; Fig. 9A shows how a table 
with a nested table would be unnested into a cross-product of the parent table and a child 
(nested) table; Fig. 9B illustrates unnesting into separate tables; Fig. 9C illustrates 
unnesting at multiple levels. 

Fig. 10 illustrates a case where unnesting might produce unintended 



query. 



Fig. 1 1 graphically illustrates an unnesting process and its effects on a 

Fig. 12 illustrates a process of converting a DTD to tables. 
Fig. 13 illustrates the XML encoding of a DTD definition. 
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Fig. 14 illustrates various real-time data flows. 

Fig. 15 iUustrates an operatioii of joining two inputs in a query. 

Fig. 16 illustrates real-time data flows that use supplementary information. 

Fig. 17 iUustrates dataflows depending on cached values. 

Fig. 18 illustrates branching data flows based on rules. 

Fig. 19 is an illustration of a complex real-time dataflow. 

Fig. 20 is an illustration of a GUI for specifying a data flow. 

Fig 21 is a block diagram of a schema conversion system. 

Figs. 22-26 are tables illustrating various aspects of an NRDM system. 

T^TTQn^TPTTON -T-TTP c;pT:.r.TFTC FMBODTMENTS 
maspecific smbodimentaNestedRelationalDataModelCNRDM) is 
designedtosupportHerarchicalandrdational components used to represent business 
data. Business documents are t^^ically hierarchical withmultiple repeating sets. For 
example^anordercontainsasetofrepeatinglineitems. It xnay also have a set of 

customers associated with it. 

Bu^s docmn^its used to =«imge data b=tw«a software system, 
^fhm an enterprise or between enterprises «=dtoberqnr=s=ated as coiBplex 

Weraxchical doam,ents. Tbe industry a.>d the research conmr^ity use well-tao^ 
representations such as EDI and XML to capture and represent such document. The 
systeu. described herein provides me^ods for mapping such docum^ts te aNested 
Relational format, mettrods for trar^sforming and manipulatir>g ofihese documerrts 
represented using the Nested Relational Model, converting such docun».s to 
rcla1ionalfoxmatandn.appingthemtomultipler.lationaltables.andanrethodof 

converting me datain anestedrelarionalfcrnratbaclt to an e«emal hierarchical format 
such as XML. 

Tbe system provides a method to apply declarative rules to the 
hierardncal (e.g.. XML or BDI) data to relaSonal tables and vice versa; declarafve ™l=s 
to ^chbierarchicaldata^ardatafromolherrelational or hierarchical sources; 
aeclaradverules to perform multi-stage^ormations. Ibe syst^ allows declarative 
^ansforraadonstobeappliedtobierarchical data, and iieabiIiWtetransparen.yapply 

rules to heterogeneous databases and files; as weE as in the ability to apply >nul.-s^ag= 
^fo^ations. Deleave specifioationsCsuchasSQDdescribewhattodo^^ oat. 
as opposed to procedural specifications (such as code) that descnbedhow to do ,t. 
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"Nested data" is data in a table Ibat is related to a single row of another 
table. Sales orders are often presented using nesting: the line items in a sales order are 
related to a single header, For atable of sales order headers, each row includes its own 
table of line items. An example of this is shown in Fig. 1. Of course, the same data could 
be represented without nested tables. For example, the data could be represented as 
multiple rows in a slngTe-table as shown in Fig. 2, or as multiple tables related by a join as 
shown in Fig. 3. 

One source of data for a nested table is the result of a query using the 
values in the related row in the parent table. As used herein, "parent table" refers to a 
table within which another table is nested and "child table" or "nested table" refers to a 
table that is nested in a column of a parent table. A nested table is said to have a 
relationship with the table within which it is nested and where levels are associated with 
tables, a parent table would have a level that is designated with a number one higher than 
the child tables nested mthafparent table. For example. Fig. 4 shows a parent table 10, a 
nested (child) table 12 one level below table 10 and nested tables 14(a)-(b) that are nested _ 
in table 12 and are two levels below table 10. 

Preferably, a unique instance of each nested table exists for each row at 
each level of a relationship. As iUustrated in Fig. 5 . each row at each level can have any 
number of columns containing nested tables. 

Fig. 6 shows various aspects of a database system 100 that handles NRDM 
data. System 1 00 is shown comprising a metadata mapper 104 that maps DTD 102 
w/hierarchical structures to NRDM schema that are stored in schema storage 106. These 
components are shown as being part of a preprocessing section, with other portions being 
part of a real-time section, but it should be understood that all of the process or none of 
the processing might be done in real-time without departing from the essence of the 
invention. Notwithstanding that caveat, the descriptions below reference an example 
wherein DTDs are converted to NRDM schema and stored and documents are converted 
by system 100 in real-time after such conversion. 

One such real-time process involved a document 110 being passed to an 
importer, then to a transformation engine (TE) 114 and an exporter 116 to result in a 
document in a new format 118 (in some cases, the formats of document 110 and 
document 1 1 8 might be the same, but some transformation has occurred). Document 1 10 
IS a structured document, such as an XML document, an HTML page, a document having 
other stmcture, or other stmctured data object. 



PCTAJSOl/04698 



impc^rter 1 1 2 canvots the document toto NKDM so « 114 cai, 
; -v-^hdow TE114acccptBd^tamNBDMfimnat=.tetl9.utandoutputsdatam 

r:i:r-crooL=,i.«B.M(...d.=i.o^~^^^ 

. Became TElW-oper^teo^NRDM^ructures, the MBSfoiinat'om 

t^h/^4c»Lc^sed^lyasadeol^t.ve.peciaoation,th.^3.V 
"^11111 of „,nsfon^g — ^ h. effect, ht^oxtex 1 12 convert. . 

be applied. ^j^^ documents, 

Exporter 1 1 6 exports &e data in a suitable form, such as ^ 

relational tables or flat files. 

^.^Mcalh,.=tf^-^.oh.ndd=.flow.3.^o.nes.eda.ta 

J 1 ^^HKv Acta. Inc Structures of nested - 
; stn.cture.sucha.theAc.aWor^-system^^^^'^^^^^- ^^^^ 

„l,™4=ndoolt.iim5. Input scheoia 60 also shows a table Z that has col 

' °°rir— Ur^-B'ro.anestedtaWeY,«hi*in»->--^ 

— .co^mmU^d ^^^^„^,„,^,,^1^3ppea.wi*atahleicon 

raT^rp"!"----'-^-^ 
:r.^^tLo.eotis..^..^^--;— 

In a relational database system (RDb)usm^ 
2^ , r f o Q-PT TJPT Statement that is executed by 

:™d...oao.neaspeetso.«.p.es». — the,„=^^^^^ 

r™ate.hlevelo.a.ela^l.^j^— 
30 SElBCTst— naightbecoustra^t^-lu^o^y^^^^^^^ ^^^^^^^ 
a query that includes nested data might mclude a SELECT stateme 

w„, ,.theoutout-eachco,«extforfheit*utdataset«transforn>ed. 
^„...len.J.eou,ut^^^^^^^^^_^^^^^^, 

,,.,„^..«.esa.ewi.hnesteddataas.ithrelat.onaldat.hutthenew.ter.aeeo. 
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included in all the orders for each state from a set of orders, the designer would set the 
Group By clause in the top-level of the data set to the state column (Order.State) and 
create an ouiput table that includes State column (set to Order.State) and Lineltems nested 
table. The result of such an operation might result with the table shown in Fig. S. The 
result is a set of rows (one for each state) that has the State column and the Lineltems 
nested table-that contains all the Lineltems for all the orders for that state. 

Nested data can also be mmested. When loading a data set that contains 
nested tables into a relational (non-nested) target, the nested rows will be unnested. Take, 
for example, a message containing a sales order that uses a nested table to define the 
relationship between the order header and the order line items. To load the data into • 
relational tables, the multi-level must be mmested. Unnesting a table produces a 
cross-product of the top-level table (parent) and the nested table (child), as shown in Fig. 
9A. Different colunms firom different nesting levels might be loaded into different tables. 
A sales order, for example, may be flattened so that the order number is maintained 
separately with each hne item and the header and line item information loaded into 
separate tables, as shown in Fig. 9B. 

Any number of nested tables can be unnested at any depth. No matter how 
many levels are involved, the result of unnesting tables is a cross product of the parent 
and child tables. When more than one level of unnesting occurs, the inner-most child is 
unnested first, then the result-the cross product of the parent and the mner-most child-is 
then umiested from its parent, and so on to the top-level table, creating the result shown in 
Fig. 9C. 

Unnesting all tables (cross product of all data) may not produce the results 
intended. For example, if multiple customer values are included in an order, such as 
ship-to and bill-to addresses, flattening a sales order by unnesting customer and line item 
tables produces rows of data that may not be useful for processing the order. This is 
iUustrated in Fig. 10. Using the GUI, the specification of the data flowis shown in Fig. 



11. 



A DTD (document type definition) describes the data schema of an XML 
message or file. Real-time data flows read and write XML messages based on a specified 
DTD format. One DTD can describe multiple XML sources or targets. Batch data flows ■ 
can read and write data to files based on a specified DTD format. 

DTDs can be imported into the NRDM system, either directly or by 
importing an XML document that contains a DTD. During import, the NRDM system 
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contexts aUows the data flow designer to distinguish multiple SELECTS from each other 
within a single query. At any context, Ihe FROM clause can contain any top-level table 
from the input or any table that is a column of a table in the FROM clause of the next 
higher context. 

When rows of one table (a child table) are nested inside another table (a 
parent table).1he data set produced in the nested table is the result of a query against the 
first table usmg.the related values from the second table. For example, if sales 
information is available as a header table and a line-item table, the sales mfonnation can 
be orgainzed as a parent table of header information and a child table containing hne-item 
data here the hne-items are nested under ihe header table. The line items for a single row 
of the header table are equal to the results of a query including Ihe order number, as might 
be found using the following statement: 

SELECT * FROM Line Items 

WHERE Header. OrderMo = Lineltems .OrderNo 

Correlation can be used to construct a nested table from columns from a 
higher-level context hi a nested-relational model, the columns in a nested table are 
impUcitly related to the columns in the parent row. To take advantage of this 
relationship, the parent table can be used in the construction of the nested table. The 
higher-level column is a correlated column, hicluding a correlated colmnn in a nested 
table may serve at least two purposes: 1) the correlated column is a key in the parent table 
■ and 2) making the correlated column an attribute m the parent table. Including the key m 
Ihe nested table allows for the maintenance of you a relationship between the two tables 
after converting them from the nested data model to a relational model. Including the 
attribute in the nested table allows for the use of the athftute to simplify correlated 
queries against the nested data. 

Correlated columns can include columns from the parent table and any 
other tables in the FROM clause of the parent table. If the correlated column comes from 
a table olher than the immediate parent, the data m the nested table includes only the rows 
that match both the related values in the current row of the parent table and the value of 
the correlated column. 

Values can be grouped across nested tables. Thus, when a statement 
includes a Group By clause for atable with anested table, the grouping operation 
combines the nested tables for each group. For example, to assemble all the line item. 
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converts the structure defined in the DTD into an internal nested-relational data model. 
Elements below the root-level that contain other elements become nested tables and 
elements that do not contain other elements become columns. Attributes become 
columns in the coiresponding element's schema. 

The NBDM system applies the following rules to convert the.DTD to 
tables, colunms, and nested tables: 

- Any element that contains PCDATA only and no attributes becomes a column. 

- Any element with attributes or other elements (or in mixed fonnat) becomes a table. 

- An attribute becomes a column in the table corresponding to the element it supports. 

- Any occurrence of choice operators is converted to strict ordering. 
_ Any occurrence of optional operators is converted to strict ordering. 

- Any occurrence of 0* or 0* becomes a table with an internally generated name-an 
implicit table. 

After these rules have been applied, the NRDM system optimizes the 
fonnat using two more rules, except where doing so would aUow more than one row at 
the root element: 

- If an impHcit table contains one and only one nested table, then the impHcit table can 
be eliminated and the nested table can be attached directly to the parent of the impHcit 
table. For example, the SalesOrder element might be defined as follows in ttie DTD: 

<!EIjEMKKrT SalesOrder (Header, Lineltems*) > 

When converted, the Lineltems element with the zero or more operator would 
become an impUcit table under the SalesOrder table. The Lineltems elenaent itself 
would be a nested table under the implicit table, as shown in Fig. 12A. Because 
the implicit table contains one and only one nested table, fee format would be 
optimized to remove fee inq)licit table, as shown in Fig. 12B. 

- If a nested table contains one and only one implicit table, then fee implicit table can 
be eliminated and its columns placed directly under fee nested table. For example, fee 
nested table Lineltems might be defined as follows in fee DTD: 

<!ELEMENT Lineltems (IteinHuia, Quantity) *> 

When converted, fee grouping wife fee zero or more operator would 
become an implicit table under fee Lineltems table. The ItemNum and Quantity elements 
would become columns under fee implicit table, as shown in Fig. 12C. Because fee 
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Lineltems nested table contained one and only one impHcit table, it would be optimized 
to remove the implicit table, as shown in Fig. 12D. 

If the DTD contains an element that uses an ancestor element in its 
dejBnition, the definition of the ancestor can be expanded for a fixed number of levels. 
For example, given the following dejBnition of element "A": 

A: B, C 
B: E, F 
F: A, .H 

The system produces a table for the element 'T" that includes an expansion of "A." In this 
second expansion of "A," "F" appears again, and so on until.ihe fixed number of levels. 
In the final expansion of "A," the element "F" appears with only the element "H" in its 
definition. 
Real-Time Sources 

A real-time source in a real-time data flow determines the message that the 
real-time data flow wiU process. The source object represents the schema of the expected 
messages. Messages received are fit to the schema. Real-time data flows accept 
real-time source types such as Extensible Markup Language formatted (XML) messages 
or intermediate documents, such as IDocs pubHshed fi-om an SAP R/3 appUcation server. 

The fonnat of the XML message.is specified by a document type 
definition (DTD). The DTD describes the schema of data contained in tbe message and 
the relationships among the elements in the data. For a message that contains iiifomiation 
to place a sales order-order header, customer, and line items-the corresponding DTD 
includes the order structure and the relationship between data, as shown by the example 
in Fig. 13. 

The following examples provide a high-level description of how real-time 
data flows address typical real-time scenarios. Fig. 14A shows a real-time dataflow as 
might be used to load transactions into an EKP system, such as SAP R/3. A real-time 
data flow can receive a transaction firom an electronic commerce application and load it to 
an EKP system. Using a query transform, one can include values firom a data warehouse 
to supplement the transaction before applying it against the ERP system. 

Fig. 14B shows a real-time data flow for collecting ERP data into a 
warehouse. Real-time data flows can receive messages firom the ERP through IDocs. 
Each IDoc contains a transaction that the real-time data flow can load into a data 
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warehouse or a data mart. In this way, IDocs can be used to keep the data in a warehouse 
current. 

Fig. 14C shows a real-time data flow for retrieving values from a cache or 
and ERP system, ms allows for real-time data flows that use values from a data 
warehouse to determine whether or not to query the ERP system directly. 
RnpplftTn'entarv Sources 

When more data is needed than what is provided in the content of a 
message to complete the message processing, supplementary sources might be used. For 
example, processing amessage that contains a sales order from an electronic coimnerce 
application that contains the customer name might require that, when the order is appHed 
against your ERP system, more detailed customer information is needed, hiside the 
real-time data flow, the message is supplemented with the customer information to 
produce the complete document to send to the ERP system The supplemaitary 
information may come from the ERP system itself or from a cache containing the same 
information cached Examples of such data flows are shown in Figs. 15, 16A, 1 6B. 

Tables and files (including XML files) as sources in real-time data flows 
can provide this supplementary information. The real-time data flow extiiacts data from 
the supplementary source as indicated by the logic defined in the real-time data flow. 

Tables or files that are used as sources and have a cache option allow for 
the data extracted to be stored in memory until the data flow processing is complete, hi 
real-time data flows, sources should not be cached unless the data being cached is small 
and is unlikely to be updated in tiie hfe of the real-time data flow. 

hi batch data flows, cachmg can improve the performance of data flow 
processing by reducing the number of times a set of data is read from the database or file 
source, hi real-time data flows, however, the improvement in performance provided by 
cachmg is mmimized by the likelihood that the real-time data flow reads only a small 
amount of data from the source for any given message, hi addition, because the real-time 
data flow reloads cached data only when an access server shuts it down and restarts it, 
cached data may become stale in memory. 

Tables can be sources in real-time data flows after their metadata is 
imported into the repository. When the real-time data flow starts, it opens a coimection to 
the source database. This connection remains open as long as the real-time data flow is 
running. If a table is included in a jom with a real-time source, the data set from tiie 
real-time source is included as the outer loop of the join. 
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Kfl tabte= c^b^so^^esinrcal-tasd^flaws after thorm^dat. is 

ABAP prcgrams B tege amounts of data m a batch systam. 

DTD that describes the data in the file is imported. 

^;:^:^ded m ■ne.sag^ fiom real-time somces may not 

defined in ^ereal-tbne data flow to supplement «>em«sagenrforn*onO^, 
te^lententing«»datainareal.timesour.it.,ude.theae«eps,nare3l-.n»data ^ 

flow: . , , ^, 

, ^oiudeatableorfileasasource. m addition to reai-ttae source, mclude ^e 

files or tables that si^ly the supplementary infcrmation. 
2 „seaquerytoe*actneededdataftomfl>etableorfile.Use«»aatairr.be 

Itile^urcetofirtdtbeneededsupplementarydat. ^^"^T^rT^ 
, , Ledinflte^sothatonlytbespecificvaluesre^Somtbes^lementary 

source are extracted. 

K,16Ashow.^examplewhereamessage includes sales order i^ormation^th^^e 

JL^^^oaltoretumordersta^. ^ '"^ 

.^ber.dprror,tyrat.s.determinetheWo.s^^«^^^ 

:S i^cludesonlythecustomernamearrdtheordernumber. ^''^^ 

definedtoretrievetbecustomernumberartdratingftomothersourcesbeforede 

""^„.-time data flow might include logic to deterrninewbenresponses^ 
. <v™ data in a cache and when they must be generated from data in an EM 

flow (iUustrated in Figs. 17-20): 
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1 . Detennine the rule for when to access the cache and when to access the ERP 
system. 

2. Compare data from the real-time source with the rule. 

3 . Define each path that could result from the outcome. Consider the case where the 
rule indicates ERP access, but the ERP system is not currently available. 

4. Merge the results from each path into a single data set. 

5. Route the single res\ilt to the real-time target. 

This example describes a section of a real-time data flow that processes a new sales order. 
The section is responsible for checking the inveatoiy available of the ordered products-it 
finds an answer to the question, "is there enough inventory on hand to fill this order?" The 
rule controlling access to the ERP system indicates that the inventory (hiv) must be more 
than a pre-determined value (IMargin) greater than the ordered quantity (Qty) to consider 
the cached inventory value acceptable. The comparison is made for each line item in the 
order. 

Fig. 1 8 illustrates a branch in the data flow based on a rule. An XML 
source contains the entire sales order, yet the data flow compares values for line items 
inside the sales order. The XML target that ultimately retiams a response requires a single 
row at the top-most level. Because this data flow needs to be able to determine inventory 
values for multiple line items, the stiiicture of the output requires the inventory 
information to be nested. The input is akeady nested under the sales order; the output can 
use the same convention. In addition, the output needs to include some way to indicate 
that the inventory is or is not available. 

Fig. 19 illustrates several ways to return values from the ERP. For 
example, a lookup function or a join on the specific table could be used in the ERP 
system. The example uses a join so that the processing can be performed by the ERP 
system rather than the KiRDM system. As in the previous join, if a value might not be 
returned by the join, an outer join can be defined so that the line item row is not lost. 

Fig. 20 illustrates a GUI used to specify transformations and a specific 
transformation specified with that GUI. 

Fig. 21 is a block diagram of a schema converter. In the example shown, 
an NRDM schema is converted to a DTD schema. 
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ofhow^any levels om=r3r=by«.p«.=n.0^m=..odofeffe^^jl.a 

Lies fox =.^.owbav.correspond.ng formats. fted^repre.=r«.gfl»*l^«^^ 
. ^l^s«uc»«.th=»^fem>aaon=.gin.de.:.wim^.da<.*uc««s.^ 

opa-ate on conventional reMond tables. i„terfac=s (APIs) 

Theapplica.lot^oft=nptovid.=wU=ationprogramnungmt=rfac^(API ) 

„.i„t«ractw>ftflie application. Often, the designer of a 
25 tteoughwitiothcrprogramsmteractwftfl. ^ ^ specify 

.1,., irtmcts With the anpUoation must know the mterjaces <ui 
program that mteractswitnm ye ™li-,tions might accept as 

an input NRDM data or a h^era^Mcal docunxent. in son.e cases, the a^^^^^ 
could .e such that the sen^anticsofthefi^Bction call are inadocu^e^ 
could he sucft tnai iieeded to call the application. 

30 parameter and then one generic interface is all that is neea 

f.rn-mT>lpTmplmientation ,.rinus asnects of the 

AnexampleofanNRDMsystemaccordmgtovanousaspectsol 

,_t— wiUnLhcde^crihed. lt.onldhe.dc.W^~ 

totted ,0 «s specific example. The example system supports taerarotocal 
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such as IDoc and XML and provides for a hierarchical structure to support a hierarchical 
data model represented as a single row that contains scalar colunms and repeating 
groiq)(s) of embedded rows forming nested table(s), where nesting can be arbitrarily deep 
and an implicit relationship is not required between embedded rows and parent (i.e., the 
5 children rows do not need to contain a key to join it back to the parent row). 

The NRDM Systran can capture an enfirelausiiiess transaction in a single 
hierarchical structure and transform a hierarchical structure as a single entity using 
relation operators that can be appHed at any level of the hierarchy. A hierarchical 
structure when applied as a suagle database transaction can be loaded to a set of tables 
10 belonging to a single datastore. 
Data Model 

In NRDM, the first normal form requirement that a column be a scalar is 
removed. In NRDM, a column can be a scalar or.a relation value, which we refer to as a 
nested table. A scalar column definition has a name, type (hicluding length, precision, 
1 5 domain info, etc.) and, at run time, contains either a value or a NULL indicator. A nested . 
table definition has a name, schema (e.g., a list of column definitions) and, at run time, 
contains either one or more rows of the schema specified in the nested table definition or 
an empty table indicator (e.g., ISEMPTY). 
DDL Operations 

20 AL_NESTED_TABLE is used below to define a nested table for DDL 

operations. For example, creating a view with nested table might be done by the 
following statements: 

CEEATE VIEW VI ( 

0KDER_ir) INT, 
25 PROD_INF0 AL_NESTEr>_TABI.E ( 

PROD_ID INT, 
QTY INT, 

VENDOR INFO AL NESTED TABLE (VNDR_ID CHAR (5) , 

- ~ VlIDR_CITy CHAR (65)) 

30 ) ' 

CID INT , 

CCITY CHAR (55) 
) ; 

Fig. 22 illustrates a data table that might result for the above statements. 
35 DMT ■ Operations 

Relational operations such as select, project, etc. can be used on NRDM 
data. Nested relations can be accessed as regular relations in the context (scope) of their 
parents. In other words, wherever a scalar column is used, a nested table can be used. If 
a parent table is used in a FROM clause, all the nested tables can be used in the SELECT 
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WHERE clauses =nd nested subcrames^^M-fledgedtabks. If two pa«^^ 
having asamename for ane^d table =xe used in a relation.1 operation, tteno^d tables 
should be qualified with the parent tables. 

Nested snibqueries allow fox accessing and transfimning data inside nested 
rdation^Ne^edsuhqueries can tomsformdatain nested relations, nest, unnestandjom 

aaami»sted relations withthedata in itsparents and handle operation, such as 
ISEMPTY AL_NEST,ALJ«ST.SETandAL.UNNESTforN5I.M data. The 
AL NEST ope^torcreatespardtionsbased on me formadon of ecpivalence classes to 
gen^^nested tables. 1, operates on a row basis. AX._NEST_SET operator . smnlar to 
ALNESTbutop^atesonasetbasia. The AL.UNNEST operator transforms a relahon 
into'cn^whichis less deeply nestedby concatenating each tuple intherelationbemg 

unnested to the remaining attributes m flie relation. 

The AL_-NEST operator creates partitions based on the formation of 
equivalence classes to ;^erate nested tables. Two h^les are equivalent if ^ey have Arc 
samevaluesforatnibut=s,whicharenotbemgnested.AL.NESTopera«scnarow ^ 
basis. Nesting canbc done in two ways usmgauserint^eCsuch as «re GUI described 
above). Anested table canbetaggedftomflreinp^ to fheou<pu.ofaqu«y«^or,n 
andplacedatthe same or deeper level, oranestedschenmcanbe^eated and columns 
ftom to input can be dragged and dropped into the newly created schema. 

, An BipUcit FROM clause mi^t be needed where two views are commg 

i.toaqu.ry«.nsform.andcolunmsares=le^edfromonlyoneftcviews. Thegenerated 
™eis to select ftomboihflre views. For nestingoftwo input Views contaunngou^y 
scalar cotamns, saluting ftomtobotttoviewsatfte same levelmight no.be desned. 

The following example illustrates this. Given a flat view VI as: ^ 

, VIEW OjmERS lOJinEE.n. IBT, PROD HIT, OW DH, 

fl.etableoffla.relationsshowninFig.23results. A two level nesting to mclude vendor 
irformation using a JOIN can be demonstrated by the following example: 

vxBw V. <-^^si;«^_T^- "^™a^S; 

35 VENDOR_INFO 

" VMDR_ID CHAS(5) , 

VKDE_CITy CHAE.(65) 
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40 



45 



) 

) , 

CID, 
CCITY 

) 

AS SELECT OEDER_ID, 

A1._HEST (CREATE VIEW PR0D_1NF0 {PIlOD_ID INT, QTY INT) 
AS SEIiECT prod" ID, 
QTY, 

AL_IIEST (CREATE VIEW VENDOR_INF0 
(VNI>R_ID CHAR (5) , 
VNDR_CITy CHAR(S5)) AS 
SELECT VjroR_ID, VOT»R_CITY 
FROM VENDORS 

WHERE VENDORS . PROD_ID = L1.PR0D_ID 
) 

AS VENDOR_IHFO 
FROM ORDERS 11 

WHERE Z,a.ORDER_ID = I,0.OEDER_ID 

il.CID = LO.CID MTO 

Iii.CCITY = LCCCITY 

) 

AS PROD_INPO, 
CID, 
CCITY 
FROM ORDERS LO 

The expHcit FROM clause prevents the usage of the VENDORS in the 
outermost select. This may produce a nested table as shown in Fig. 22, except with three 
rows with ORDER_ID equal to 100, two rows with ORDER_ID equal to 200 and one 
row with ORDER_rD ^ 300, because ALJMEST operates on a row basis, which can 
produce duplicates. 

The AL_NEST operator may be losed to perform nesting on a set of rows 
also. If there is a GROUP BY. the set formed by the GROUP BY is used. If there are 
aggregate functions and a GROUP BY is specified, the set formed by the GROUP BY is 
used. If there are aggregate functions and a GROUP BY is not specified, then the default 
grouping is the entire table. AU nested tables in the set operated by the AL.NEST may 
be merged. 

TTsing AL NEST SET with an Aggregate Function 

This operation may take in a view with nested tables and produce a single 
row, which has count of ORDER_rD's and the merge of all nested tables: 

CREATE VIEW V2 (NUM_ORDERS INT, 

PROD INFO AL NESTED_TABLE (PROD_ID INT, 
~ QTY INT 

) 

) 

AS SELECT COUNT (ORDER_ID) , 

AL NEST_SET (CREATE VIEW PROD_INFO {PROD_ID Il^TT, 
QTY INT) AS 
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SELECT PROD_ID, QTY 
FROM PROr>_INF0 

) 

PROD_INFO, 

FROM VI 

Such a query might produce the table shown in Fig. 24. If the nested table(s) SELECT(S) 
have "WHERE clauses, the nested table(s) might first be merged and the filters applied to 
the merged table(s). 
ALUNNEST 

The AL_IINNEST operator transforms a relation into one that is less 
deeply nested by concatenating each taplt in the relation bemg unnested to the remaining 
attributes in the relation. To unnest the vendor informadon from the nested table in Fig. 
22, the following ATL might be defined: 

CREATE VIEW V2 (ORDER_lD INT, 

PROD INFO Uj MESTED_TABI.E (PR0D_ID INT, 
~ QTY INT, 

Vl!lDR_ID CSAR(5)) ) 

AS SELECT ORDER ID, 

J^JHEST (CREATE VIEW PR0D_INF0 (PR0D_ID INT, QTY INT) AS 
SELECT VI . PR0D_INFO . PROD_ID, 
VI . PROD_IlirFO . QTY , 

XL UMNEST (CREATE VIEW VDR_INFO 
(VNDR_ID INT) AS 

SELECT 

VI . PROD_INFO . VENDOR_INF0 . VNDR_ID 
FROM VI . PROD_INFO . VENDOR_INFO ) 

FROM V1.PROD_II!TPO) 
AS PROD_INFO 

FROM VI . ■■ J -IT 

WHERE clauses can be apphed in the SELECT for unnestmg by dnlling 
into the tested table which would produce a query transform, specifying the condition 
there, as shown in the following example: 

CREATE VIEW V2 (VKDR_ID CHAR (5), VNDR_CITY CEAR{6S)) 
AS SELECT DISTINCT AI._DHHEST (CREATE VIEW 

■ONESTl (VNDR_ID CHAR (5), 
VNDR_CITY CHAR (65)) 
AS SELECT 

AL_'DKHEST (CREATE VIEW 

UHEST2 (Vl>rDR_ID CHAR (5 ) , 
VNDR_CITY 
CHAR (£5)) 
AS SELECT VKDR_ID, VNDR_CITY 

FROM VEKDOR_INFO) 
FROM PROD_INF0 

) 

FROM VI 

An example of a simple projection firom one hierarchical structure to 
50 another would be: 
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CREJITE VIEW V2 { 

OEDER_ID INT, 

PROD_INFO AIi_HESTED_TABI.E {PROD_ID XNT, QTY INT) 
) 

AS SELECT ORDER_ID, 

AL MEST (CREATE VIEW PROD_INFO (PROD_ID INT, QTY INT) 
AS SELECT V1.PROD_INPO.PROD_ID, VI . PROD_IHF0 . QTY 
FROM Vl.PROD_INFO) 
AS PROD_IKF0 

FROM VI 

The qualifier VI. PR0D_INFO in the nested relation is not really needed; the nested 
query could have been written using just PROD_INFO. The result might be the table 
shown in Fig. 25. 
Select 

Filter conditions can be apphed at various levels. Consider the example of 
view VI (Fig. 22) that has three levels of nesting. A filter on the nested relation 
PROD_INFO might be implemented as follows: 

CREATE VIEW V3 {ORDER_ID INT, 

PROD_INPO AL_JIBSTEn_TABLE(PROD_ID INT, QTY INT) 

) 

AS SELECT 

ORDER ID, 

Al._NEiT. (CREATE VIEW PROD_INFO ( PROD_ID INT, Qry INT) 

AS SELECT VI . PROD_INFO . PROD_ID , 

VI . PROD_mFO . QTY 
FROM V1.PR0D_INF0 
WHEEE Vl.PROD_INFO.QTy > 50) 

AS PROD_INFO 

FROM VI 

• This may select all the rows fi-om VI, but for the nested table PROD_INFO. only those 
rows are chosen where the quantity ordered QTY is greater than 50, resulting in the table 
shown in Fig. 26. 

Alternate S iip port For Filters In Th e WHERE Clause 

For a nested table to be used in a WHERE clause sub-query, support 
within a WHERE clause should be available. If such support is not available, it can be 
overcome by using two stages and the ISEMPTY operator for nested tables. Nested 
tables can be used in a WHEI^ clause only with the ISEMPTY operator. The foUowing 
example illustrates the use, selecting all the rows from VI that have ORDER_ED greater 
than 100 and that have at least one product with a quantity ordered greater than 50. 

CREATE VIEW V3 (OPJ3ER_XD ItTT, 

PROD_INFO AL_NESTED_TABLE(PROD_ID INT, QT^ INT), 
TEMP_PROr)_INFO ja._NESTED_TABl.E (PROD_ID INT, QTY 

INT) 

) 

AS SELECT 

ORDER ID, 
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1^ST(CRS.TE VIEW PROP.INFO (PROD^D IHT, QTT INT) 
- AS SELECT V1.PROD_IKFO.PROD,ID. 

VI . PROD_INFO . QTY 
FROM V1.PR0D_INF0 

^ ^-S^iE VX» rR0D_I3^(H^-^ IKT, Q« IKT, 
AS~SELECT VI . PROD_IHFO . PROD_ID , 
VI . PROD_ISrFO . QTY 
PROM V1.PR0D_INF0 

S Vl.PROD_INFO.QTy > 50) 



Join 



as TEMP_PROD_IOTO 
FROM VI WHERE V1.0EDER_ID > 100 

CREATE VIEW V4 ■(°^J^^,^>s^_:r«x^(PROD_IX) INT, QT^^ XNT) 
) 

AS SELECT 

rSi??^3^TE VIEW PROI,_IKPO(PROD_IB INT, QTY INT) 
AS~SELECT Vl.PROD_IHPO.PROD_ID, 
VI . PR0D_IKFO . QTY 
FROM V1.PR0D_INP0 

) 

AS PROD_INF0 
FROM V3 WHERE ! ISEMPTY (TEMP_PROD_INFO) 

Nested teladons canbe jomed with any other relations. An exanaple is 



^ven below: 

CHEATE VIEW ^^^J^^^^^ I^S^^'^St , PROBI^ VARCH^O. (XO) ) ) ; 

35 • CRKATE VIEW VENDORS (PROniB INT, ^^^^^^ (,0) ) ; 

CHBATE VIEW OHnBRS_WITH_V^O^ (ORD^X^IHT^ ^^^^ ^^^^^^^io. 

BROUUuiB _ iRODHAME VARCHAR (10) , 

40 VEHDORID INT) 

rSS' vx.« ~s,P.onx^^^,,„, , 

45 VENDOE.ID INT) 

AS SELECT PRODID, PRODNAME, VENDORIC 

FROM PRODUCTS, VENDORS pRODID) 
WHERE PRODUCTS. PRODID = VENDORS - PRODID ) 

cn AS PRODUCTS 

FROM ORDERS GROUP BY ORDERID 
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Nested Table Transfoim 

• A system transfoim is available that takes in a flat view and produces a 
singleton that has a N integer scalar column with a value 1 , and a nested table containing 
the input view. 

Tables as Parameters 

- ■ Tables can be used as parameters for imported functions. Given a function 

get_orders with an input parameter customerjd and an output parameter orders: 

CEEA.TE FONCTION get_orders (cust:_id int. , , . ^ , 

■orders ALJHESTEDJTABLE (order^ad inti, ~J 

ODTPUT, 

cust_info AI._HESTED_TABI.E(ouBt_naine, . . ) 

OTJTPUT) ; 

Get orders for each customer by calling the orders function: 

CREATE VIEW customer_orderB (cuBtomer_id int* #«^Jo-,. -iri 

^-^^ oxders AL_MESTED_TABr.E (ordex_3.d 

- int, _) ) 

AS SELECT cust:omer_id, r.-^A^Ts\ 
ALJNEST (get_orders (cms tomer_id) :: orders) 

AS orders 

FROM customers; • j *i. 

if the function has multiple tables as outputs, and all or some of Ibem are required, then 

the function has to be mvoked multiple times: once for each output 

CRIIA.TE VXEW customer orders (customer_id int, , ^ ^« \ 

CREATE vxfiw cu _ ^_;g^S5EI,_TaBLE(cust_naTne,.. .) , 

~ orders A1._HESTED_TABLE (order_id 

int, _)) 

AS SELECT customer_id, • , , _ 

AS ^^j^g^ Tget_orders (customer_id) : :cust_info) AS 

cust_info ^^^^ {get.orders (customer.id) :: orders) AS orders 
FROM customers; , 
As an optimization, the system could invoke the function only once and use those results 

for different instances within the query transfomi. For mapping a function returning 
table, a user would create a nested table column and map the nested table colunm to tbe 
function returning a table. The schema of the nested table may then be identical to the 
schema returned by the function. This is a concept of a "generated table". The schema 
definition of generated table cannot be modified, and it should disappear when the 
function is removed from the mapping. It should be represented differently in the UI so 
that a user can distinguish between a generated table and a non-generated table. 
TTiRrarchical File Reader 

A hierarchical file reader reads data generated by data flows that have 
functions that return tables. There are two main alternatives: model the file reader as an 
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XML file reader or model the file reader using a proprietary format to represent 
hierarchical data. 

Effect of NRDM on Svst eTn Transforms 

System transforms such as Table_Comparison, Hierarchy_Flattemng, etc. 
accept only rows with scalar columns. 

T-aM-e Comparison : The output schema of the table comparison transform 
is a generated schema and is same as the schema of the table being compared against. 
This transform may silently ignore columns that are nested tables. 

TTistorv Preserving : The output schema of the history preserving transform 
is same as the input schema, and this transform may preserve history only scalar columns 
and may act as pass through for columns that are nested tables. 

P-fFfirtTveDate : The transform may act as pass through for colunms that are 

nested tables. 

tTpv Generation : The output schema of the key generation transform is 
same as the input schema, and this transform may act as pass through for colunms that are . 
nested tables. 

Ma p Oneration : The output schema of the map operation transform is 
same as the input schema, and this transform may not aUow operations to be mapped for 
columns as nested tables and may act as pass through for them. 

TTi^rrhvinattening : Columns as nested tables cannot be a parent or child 
column of a hierarchy, but they can be dragged and dropped attribute columns and thus 
can appear in the output schema. 

Pivot : The output schema of the hierarchy flattening transform is a 
generated schema and columns, as nested tables may be ignored. 
A Case Study 

A case smdy of a Sales Order IDoc using mCDM was performed. The 
IDoc was captured in a NRDM and perform transformations, to arrive at the same result 
as if the NRDM was not used, but with simplified specification of the transformations. 

An IDoc is divided into a control record, data records and a status record 
. Each control record and status record has numerous fields. For our purpose of vahdatiag 
the mDM, we treated control records and status records as single varchar columns. The 
ATL to represent a Sales Order (some of the columns associated with nested tables might 
be omitted in the fisting) is: 
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C3iEATB VIEW VI ( 

C0NTR0L_RECORD VARCHAR (100) , 
STA,TUS_RECORD VTiRCHAR (100) , 
E2CMCC0 AL_NESTED_TABIiE ( 

ZEITP VARCHAR (2) , • • « 
E2CVBtrK AL_HESTED_T2VBI.E ( 

SUPKZ VARCHAR (1), .., 
E2CVBAK AIj_IIESTBD__TAB1iB ( 

~ i5UPKz'"vARCHAR (1) , 



AI> MESTED_TABliB ( 



E2CVBK0 AIi_NESTED_TABU3 ( 

SUPKZ VARCHAR (1) , 

E2CVBP0 AL_NESTED_TABl4E ( 

STIPKZ VARCHAR 

:(1) , 

) . ■ 

E2CVBAP Al,_ireSTBIJ_TABI.E ( 

S0PKZ VARCHAR (1) , 
E2CVBA2 



VARCHAR(l) , 
) , 



AL_HESTED_TABLE ( 



SUPKZ 
, VARCHAR (1) , 



aLi_IIESTED_T. 



AL_lIESTED_TABIiB { 



VARCHAR (1.) 
) , 

E2CVBKD 



AI._NESTED_TABI.E ( 



All MESTBD_TABIiE ( 



SUPKZ 
VARCHAR (X) , 



E2CVBPA 



SUPKZ 
VARCHAR (1) , 



AI._HESTED_TABLE ( 



AI,_KESTED_TABLE ( 



SUPKZ 
VARCHAR (1) , 



E2CFPLT 



SUPKZ 
VARCHAR (1)., 



lLl._NESTED_TABIiE ( 
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SUBKZ 
VHRCHRS. ( 1 ) , 
) , 

) , # E2CVBAP 
) , # B2CVBAK 
) , # E2CVBVK 

) # Ezascco 

) # VJ. 

The ATL coireiondiiig to the population of the sales order fact table from 
the above view may be (with some colimms omitted for illustration purposes): 

CBBATE VIKW V2 ( SO KUM, # VBAK.VBELN 

CREATE VIEW ^ VBAK.KOMNE 

LIKE ITEM_ID, # VBAP.POSWE 

CREATE DATE. # VBAP.ERDAT 

SHIP_TO, # VBPA.KnUHR 

DELIVEIlY_STATnS # VBtTP - iFCSSA 

) 

20 AS SELECT AIi_trNNEST 

(SEliECT AL_ONKEST 

(SELECT AIi_DMNEST 

(SELECT VBELN, KDKMR, 

Al miNEST (SELECT POSNR, EEMT, 

- AL_DMMEST (SELECT KDMMR FHOM 

E2CVBPA WHERE PARVW = 

' iLLjamrssT (select lpgsa from 

30 E2CVBUP) E2CVBAP 

) 

FROM VI . E2 CMCCO . E2CVBUK . E2 CVBAK 
) 

35 FROM V1.E2CMCC0.E2CVBUK 

) 

FROM V1.E2CMCC0 

) 

FROM VI 
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WRATTS CLAIMED IS: 

1 1. An apparatus for processing data representable in a hierarcMcalfoim, 

2 the apparatus comprising: 

3 an importer having inputs to receive a schema and a structured document from a data 

4 source, wherein the importer outputs, a first nested relational data model 

5 (NKDM) data structure representing the structured document according to the 

6 received schema; 

7 an transformation engine that is capable of transfoiming the first NRDM data 

8 structure output by the importer into a second NRDM data structure according to 

9 a declarative specification of a transform; and 

10 an exporter having an input to receive the second NRDM data structure, wherein the 

1 1 exporter outputs a transformed hierarchical document in a data structure other 

12 than an NRDM data structure in a form suitable for a data target. 

13 2. The apparatus of claim 1, further comprising means for converting 

14 relational data to an NRDM data structure by vertically partitioning a relation and nesting 

15 parts of the relational data as a nested table. 

16 3 . The apparatus of claim 1 , further comprising means for converting 

17 nested relational data to relational data by nnnesting the nested tables using a 

1 8 cross-product between a parent row and a child subtable. 

19 4. The apparatus of claim 1, fiarther comprising means for performing a 

20 grouping operation on a nested table that generates a resulting nested table containing a 

21 union of all the nested tables grouped by the operation. 

22 5. The apparatus of claim 1, further comprising means for performing 

23 multi-step transformations, wherein an input to a transformation is results of a previous 

24 transformation, a data source, or both. 

25 6. The apparatus of claim 1 , wherein the transformation engine operates o 

26 rules that are applied to data independent of data format. 

27 7. The apparatus of claim 1 , wherein the exported is adapted to output onf 

28 or more of an XML file, a relational table or a flat file. 
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29 8. A metadata mapper comprising: 

30 an input for receiving a docmnent description for hierarchical docmxents; and 

31 an output for outputting anNRDM data structure representing the docmneat 

32 description. 

33 9. Anapparatusfortransformingdatarepresentableinahierarchicalform, 

34 the apparatus comprising: 

35 an importer having inputs to receive a schema and a structured document from a data 

36 source, from a data transformer, orfiombolh, wherein the importer outputs a 

37 first nested relational data model (NKDM) data structure representing the 

38 staictured document according to tlie received schema; 

39 an transformation engine that is enable of transforming the first NRDM data 

40 structure output by the importer into a second NRDM data structure accordmg to 
4X a declarative specification of a transform; and 

42 an «q,orter having an mput to receive the second NRDM data structure, wherein the 

43 exporter outputs a transformed hierarchical document in a data structure other 

44 than an NKDM data struchrre in a fonn suitable for a data target 



10. A method for providing data to an appHcation through a data platform 
in a computer system in response to request from the application, the method comprising: 
accepting declarative rules for accessing the data from data sources and declarative 

rules for transforming tiie data mto a format requested by the appKcatiom 
mapping relational and non-relational data sources to an NKDM data structure; 

50 interpreting a request; 

5 1 retrieving data from the data sources; 

52 transforming the data according to the declarative rules; and 

53 returning the Uransformed data to the appUcation. 

54 11 . The method of claim 10, wherein requests are processed as messages 

55 and request messages contain sufficient information to drive data extraction into a 

56 data-oriented interface. 

57 12. The method of claim 10, wherein the requests are appHcation 

5 8 programming interface fimction calls. 
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59 13. A method for updating a plurality of data targets from a message, 

60 comprisiiig: 

61 makiiig an update request through a data-oriented interfece; 

62 specifying declarative rules for updating the data targets; 

63 importing metadata that maps relational and non-relational data targets to NRDlv 

64 data structures; 

65 interpreting incoming update requests; 

66 transfoiming the data according to the declarative rules; and 

67 updating the data targets. 

gg 14. The method of claim 13, further comprising: 

69 making an update request using an appHcation; and 

70 causing one of a response to be sent to the application, an update of data, or bod 

71 15. The method ofclaim 13, ftuiiierconiprising a step of combining 

72 update request with other data before updating the data targets. 

73 1 6. A method of providing input to an application expecting one or i 

74 tables as parameters to an input message, the method comprising: 

75 mapping data in a NRDM data structure to function parameters; and 

76 maldng a function calls to the appUcation using the NRDM mapped data structi 
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The WHEREclause jains thenvo inputs, resuHina in 
output fear only the sales docuiront and Im© tome 
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CaclieOIC, si Ihe nested-level context: 
WHERE Com pateasache.UneltBms.Qry < 
(Cornpare2cacho.Linelicms.INV + 
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ClieckERP, a1 tie nested-level context: 
WHERE CDmpare2=ache.LineliBms.Qty >= 
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